The present invention relates to the field of synchronizing software execution, e.g., synchronizing multi-threaded execution of a program. One embodiment of the invention also relates to the field of computer-based testing of products or devices.
In the software arts, when working with multiple threads or processes, the problem of execution synchronization often arises. As used herein, execution synchronization may refer to any of various techniques enabling multiple threads or processes to execute together effectively. For example, one aspect of execution synchronization pertains to coordinating multiple threads or processes to share data or resources. For example, when one thread is writing to a file, other threads may need to be prevented from doing so at the same time in order to prevent data errors in the file. Also, threads may need to be prevented from reading from the file while it is being written to, in order to ensure that partial or incorrect data is not read.
Another aspect of execution synchronization pertains to defining and enforcing a series of operations that must be performed atomically. For example, consider a program where one thread updates a static data structure containing X and Y coordinates for items to be displayed by another thread. If the update thread alters the X coordinate for an item and is preempted before it can change the Y coordinate, the display thread may be scheduled before the Y coordinate is updated, resulting in the item being displayed at the wrong location.
Other aspects of execution synchronization include: forcing a group of threads to wait for each other until proceeding past a specified location; enabling threads to pass data to each other, e.g., so that a consumer thread can use data produced by a producer thread; notifying one or more threads when a particular event or condition occurs; etc.
In the prior art, various types of xe2x80x9csynchronization objectsxe2x80x9d have been used in synchronizing execution among multiple threads and processes. For example, one type of synchronization object is a mutex. A mutex (short for mutual exclusion) may be used to guarantee exclusive access to a shared resource, typically by controlling access to the resource through xe2x80x9clockxe2x80x9d and xe2x80x9cunlockxe2x80x9d operations. For example, referring to the above example of the update and display threads, to solve this X,Y coordinate update problem, the update thread may lock (acquire) a mutex indicating that the coordinate data structure is in use before performing the update. The update thread may then unlock (release) the mutex after both coordinates have been processed. The display thread must wait for the mutex to be unlocked before updating the display. This technique of waiting for a mutex is often called xe2x80x9cblockingxe2x80x9d on a mutex because the thread or process is blocked and cannot continue until the mutex is released. Other types of synchronization objects known in the prior art include semaphores and queues.
Programmers often find it difficult to properly implement execution synchronization using synchronization objects such as a rendezvous, mutex, or semaphore. For example, in the prior art, the programmer is typically responsible for coding and managing execution synchronization, including properly acquiring and releasing synchronization objects; defining and implementing timeout behavior when waiting to acquire a synchronization object; etc. In a complex application, this can require a significant amount of detailed work on the part of the programmer and can be difficult to accomplish.
Therefore, an improved system and method for synchronizing execution of software activities (i.e., processes or threads) is desired. It would be desirable for the improved system and method to simplify the task of implementing execution synchronization for an application. In particular, it would be desirable to abstract this task above the code-level, so that the programmer can work at a more intuitive level, e.g., using a graphical user interface (GUI). It would also be desirable to provide a method to work with a group or batch of threads at a higher level by defining xe2x80x9cbatch synchronization sectionsxe2x80x9d operable to synchronize the execution of the batch of threads in various ways.
Execution synchronization is a common problem in many types of systems and software environments. One class of systems which has heretofore suffered from a lack of ability to manage execution synchronization is the class of computer-based xe2x80x9ctest executivexe2x80x9d systems. In modern testing environments, software referred to as test executive software may be used to control or perform tests. The test executive typically allows the user to organize and execute a sequence of test modules, e.g., via a graphical user interface. For example, a test sequence may comprise a series of steps, wherein each step references a test module, and wherein each test module is executable to perform and/or control a test of one or more units under test (UUTs). Each step may have a parameter or property configuration that affects execution of the step. Test step parameters or properties may affect or control a wide variety of test aspects, such as whether data-logging is enabled for the test step, whether the step is executed in a loop, etc., as well as product-specific test aspects.
Thus, when executed, test modules corresponding to the steps in the test sequence may be operable to perform a desired sequence of tests on the unit under test. For example, various test modules may interact with instruments that measure and/or control the unit under test. For example, in a manufacturing environment, test executive software may be used to test manufactured products or devices, e.g., by executing various test modules that interact with instruments that measure and/or control the products.
Thus, test executive software operates as the control center for an automated test system. More specifically, the test executive allows the user to create, configure, and/or control test sequence execution for various test applications, such as production and manufacturing test applications. Test executive software typically includes various features, such as test sequencing based on pass/fail results, logging of test results, and report generation, among others.
The following comprises a glossary of test executive nomenclature used herein:
Code Modulexe2x80x94A program module, such as a Windows Dynamic Link Library (.dll), Java class file, LabVIEW VI (.vi), etc., or other software object or component that includes one or more functions or procedures that perform a specific test or other action.
Test Modulexe2x80x94A code module that performs a test.
Stepxe2x80x94Any action, such as calling a test module or step module to perform a specific test, that the user can include within a sequence of other actions.
Step Modulexe2x80x94The code module that a step calls.
Sequencexe2x80x94A series of steps that the user specifies for execution in a particular order. Whether and when a step is executed can depend on the results of previous steps.
Subsequencexe2x80x94A sequence that another sequence calls. The user specifies a subsequence call as a step in the calling sequence.
Sequence Filexe2x80x94A file that contains the definition of one or more sequences.
Sequence Editorxe2x80x94A program that provides a graphical user interface for creating, editing, and debugging sequences.
Run-time Operator Interfacexe2x80x94A program that provides a graphical user interface for executing sequences on a production station. A sequence editor and run-time operator interface can be separate application programs or different aspects of the same program.
Test Executive Enginexe2x80x94A module or set of modules that provide an API for creating, editing, executing, and debugging sequences. A sequence editor or run-time execution operator interface uses the services of a test executive engine.
Application Development Environment (ADE)xe2x80x94A programming environment such as LabVIEW, LabWindows/CVI, Microsoft Visual C++, Microsoft Visual Basic, Delphi, etc., in which the user can create test modules and run-time operator interfaces.
Unit Under Test (UUT)xe2x80x94A device or component that is being tested; may include software and/or hardware elements.
In the prior art, test executive software has not provided users with the ability to effectively test multiple units at the same time using different threads of execution. It would be desirable to provide a system and method for executing a batch of threads simultaneously such that each thread executes an instance of a test sequence to test a unit under test. It would be desirable for each thread to have its own execution flow but to also provide an ability to include batch synchronization sections in the test sequence to synchronize the execution of the threads where necessary.
One embodiment of the present invention comprises a method for creating a computer program to be executed by a plurality of threads, in which the method utilizes a technique for execution synchronization referred to herein as a batch synchronization section. According to this technique, a plurality of threads may be associated with one another as a xe2x80x9cbatchxe2x80x9d of threads. Each thread in the plurality (batch) of threads may execute the computer program simultaneously. The batch synchronization section may specify a portion of the computer program for which the execution of the portion by the plurality of threads is to be synchronized. For example, the batch synchronization section may specify an enter point and an exit point which together define the portion of the computer program for which execution synchronization is desired. During execution of the program, each thread that arrives at the enter point may block until all other threads in the plurality (batch) of threads have arrived at the enter point.
Once all the threads have arrived at the enter point, one or more threads may execute the program portion between the enter point and exit point and may do so in various orders. In one embodiment, different types of batch synchronization sections may be specified, wherein each type of batch synchronization section specifies a different type of execution synchronization for this portion of the program, as described below. In the preferred embodiment, each thread that arrives at the exit point of the batch synchronization section blocks until all other threads have arrived at the exit point. Each thread may then resume execution of the program from the exit point.
In one embodiment, a batch synchronization section may be specified for the computer program via a graphical user interface (GUI). For example, when using an application development environment application to create the computer program, the user (programmer) may request to specify a batch synchronization section, and the application development environment application may display the GUI in response to this request, e.g., by displaying a new window or dialog box.
User input specifying information for the batch synchronization section may be received via the GUI. For example, a batch synchronization section type may be specified. In one embodiment, the following types of batch synchronization sections are supported: parallel, serial, and one-thread-only. These batch synchronization section types are described below. Other information may also be received, such as an enter point and exit point for the batch synchronization section. The enter and exit points for the batch synchronization section may together specify the portion of the computer program whose execution is to be synchronized with respect to the plurality of threads.
User input specifying functionality for the computer program may be received, including program functionality associated with the batch synchronization section. For example, this may comprise receiving user input specifying source code for the computer program, wherein the source code defines the functionality of the program. A portion of the program functionality may be associated with the batch synchronization section, e.g., by including source code between enter and exit points of the batch synchronization section.
It is noted that the steps of receiving user input specifying information for the batch synchronization section and receiving user input specifying functionality for the computer program may be performed in any of various ways and in various orders. For example, in a typical application the user may begin developing a computer program to be executed by a plurality of threads by providing input specifying source code to implement a first portion of program functionality. During the development process, the user may realize that execution of a second portion of program functionality needs to be synchronized with respect to the plurality of threads. For example, it may be necessary that the second portion of program functionality be executed only once by a single thread (one-thread-only synchronization), or it may be necessary that the second portion of program functionality be executed by one thread at a time (serial synchronization) or by all the threads simultaneously (parallel synchronization).
Thus, the user may specify a batch synchronization section to implement the desired synchronization behavior for the second portion of program functionality. In one embodiment, the user may specify the batch synchronization section via a GUI, as described above. For example, in response to user input indicating a desire to specify the batch synchronization section, a GUI may be displayed. The user may specify a type for the batch synchronization section via the GUI, such as one-thread-only, serial, or parallel, and may then click an xe2x80x9cOKxe2x80x9d button. In response, a portion of placeholder code to implement the specified type of batch synchronization section may be automatically included in the computer program. For example, the placeholder code may include function calls or other source code defining an enter point and exit point for the batch synchronization section. The user may then fill out this placeholder code, e.g., by inserting the source code for which execution synchronization is desired. Thus, in this example, the enter and exit points for the batch synchronization section may be automatically included in the program, and the user may insert desired source code between the enter and exit points.
In another embodiment, the source code that needs to be included in the batch synchronization section may already be present in the program, and the user may associate this source code with the batch synchronization section, e.g., by using point and click GUI techniques to define the enter and exit points for the batch synchronization section. Source code to implement the enter and exit points for the batch synchronization section may then be automatically included at the indicated locations. Also, in another embodiment, the user may specify the entire batch synchronization section manually, i.e., without aid of a GUI or without any source code being automatically included in the program. For example, the user may manually include source code in the program to implement the enter and exit points for the batch synchronization section.
In response to the user input specifying functionality for the computer program, i.e., after the user has finished writing the program, program instructions (e.g., machine language instructions) implementing the program functionality may be programmatically created, e.g., in response to the user requesting that the program be compiled. The created program instructions are preferably also operable to implement the execution synchronization behavior defined by the batch synchronization section, as described below. A plurality (batch) of threads may then execute the created program instructions.
Each thread in the plurality of threads may execute the program instructions until arriving at the enter point for the batch synchronization section. Upon arriving at the enter point, each thread may block until all other threads in the plurality (batch) of threads arrive at the enter point. For example, the executable instructions for the program may include executable instructions associated with the enter point of the batch synchronization section which cause the threads to block until each thread has arrived at the enter point. In various embodiments, thread blocking may be implemented in any of various ways, e.g., using standard operating system techniques.
Once all threads in the plurality (batch) of threads have arrived at the enter point of the batch synchronization section, execution of the program functionality associated with the batch synchronization section proceeds according to the type specified for the batch synchronization section, e.g., parallel, serial, or one-thread-only. One or more threads may execute this portion of program functionality and in various orders, as described below.
Each of the one or more threads that executes the program functionality associated with the batch synchronization section may block at the exit point of the batch synchronization section until all other threads arrive at the exit point. Once all threads have arrived at the exit point, each thread may then resume execution.
As noted above, in one embodiment the following types of batch synchronization section types may be specified: one-thread-only, serial, or parallel. Once all threads in the plurality (batch) of threads have arrived at the enter point of the batch synchronization section, execution of the program functionality associated with the batch synchronization section may proceed differently, depending on the specified type.
If the batch synchronization section is a one-thread-only batch synchronization section, then exactly one thread may execute the functionality associated with the batch synchronization section. The other threads may skip execution of this portion of the program and may resume execution from the exit point of the batch synchronization section. The determination of which thread executes the functionality associated with the batch synchronization section may be made in various ways. For example, in one embodiment, each thread may be assigned a priority order, e.g., when the threads are created or by calling a function to assign a priority order to each thread, and the thread with the highest priority may be chosen to execute this portion of the program.
If the batch synchronization section is a serial batch synchronization section, then one thread at a time may execute the functionality associated with the batch synchronization section until all the threads in the batch have executed this portion of the program. The determination of the order in which the threads execute the functionality associated with the batch synchronization section may be made in various ways. For example, in one embodiment, each thread may be assigned a priority order, e.g., when the threads are created, and the threads may execute this portion of the program in priority order.
If the batch synchronization section is a parallel batch synchronization section, then all the threads in the plurality (batch) of threads may execute the functionality associated with the batch synchronization section in parallel (simultaneously).
Thus, the method described above enables the creation and execution of a multi-threaded computer program, wherein each thread has its own flow of execution but is synchronized with other threads with respect to one or more portions of the program that are defined by batch synchronization sections. The above-described method may advantageously simplify multi-threaded programming compared to techniques known in the prior art. For example, the user is not required to implement desired synchronization behavior with low-level synchronization constructs such as a rendezvous, mutex or semaphore, is not required to acquire and release synchronization object locks or maintain a count of the number of threads that have acquired a lock, etc. Instead, the plurality of threads may be grouped into a logical batch, and the batch synchronization section(s) of the program may synchronize the execution of each thread in the batch as described above, regardless of how many threads are in the batch. Thus, the number of threads in the batch may be easily changed without having to change the program code implementing the execution synchronization.
Also, the method may provide improved error-handling techniques for multi-threaded programs. For example, if one of the threads in the batch terminates, due either to normal execution flow or an error condition, then the thread is preferably automatically removed from the batch. Thus, when the other threads in the batch have all arrived at the enter point of a batch synchronization section, these threads may then proceed without waiting for the terminated thread.
In one embodiment, a xe2x80x9cbatch objectxe2x80x9d may be created to facilitate the management of a batch of threads as described above. For example, as each thread in the plurality (batch) of threads is created, the thread may be associated with or added to the batch object. The method steps described above may use information from the batch object to determine when all the threads in a batch have arrived at the enter or exit points of a batch synchronization section. Also, as threads terminate, they may be automatically removed from the batch object. In one embodiment, the batch object may be an implicit object that is created automatically and does not require management on the part of the user. In another embodiment, the user may include explicit source code in the program to create the batch object, add threads to the batch object, etc. For example, this may enable some threads to be associated with a batch of threads while other threads are independent of the batch, may enable multiple batches of threads to be defined, etc.
The above-described method may be employed to create any of various types of multi-threaded computer programs or computer-implemented processes. The programs or processes may be specified using any of various programming languages, techniques, or software development applications. As described above, test executive software applications are often used to create and control a computer-implemented testing process, e.g., to perform tests of a group of units under test. The following describes one specific application of the above-described method to specify execution synchronization behavior for multiple concurrent executions of a test executive test sequence.
The test sequence may include one or more batch synchronization sections. Multiple threads may each execute an instance of the test sequence to concurrently to test a group of units under test, and the batch synchronization sections may coordinate the execution of the multiple threads where necessary.
A plurality of steps may be included in a test sequence in response to user input. As described above, various steps may reference code modules that are executable to perform desired tests of a unit under test (UUT). A batch synchronization section may be included in the test sequence. In one embodiment, a batch synchronization section may be included in the test sequence by including an enter step, an exit step, and one or more functional steps between the enter and exit step, wherein execution synchronization is required for the one or more functional steps. In the preferred embodiment, the user may utilize a GUI to specify the batch synchronization section. Exemplary GUI dialog boxes are described below. The user may also specify a type for the batch synchronization section. In one embodiment, the user may choose from the above-described batch synchronization section types: one-thread-only, serial, or parallel.
After creating the test sequence, user input indicating a desire to execute the test sequence to simultaneously test a group of units may be received. In response to this user input, a plurality (batch) of threads may be simultaneously executed, wherein each thread executes an instance of the test sequence. Each thread may execute its respective instance of the test sequence until arriving at the enter step of the batch synchronization section and may then block until all other threads in the plurality (batch) of threads arrive at the enter step.
Once all threads in the plurality (batch) of threads have arrived at the enter step of the batch synchronization section, execution of the one or more functional steps in the batch synchronization section proceeds according to the type specified for the batch synchronization section, e.g., parallel, serial, or one-thread-only, similarly as described above. One or more threads may execute the functional steps in the batch synchronization section and in various orders.
Each thread that executes the functional steps in the batch synchronization section may block at the exit step of the batch synchronization section until all other threads in the plurality (batch) of threads arrive at the exit step. Once all threads have arrived at the exit step, each thread resumes its respective execution of the test sequence from the exit step.
Thus, the above-described method may enable a group of units to be tested simultaneously. A separate thread may execute an instance of the test sequence to test each unit, wherein each thread has its own execution flow. For example, different threads may execute different steps of the sequence, e.g., depending on execution results obtained when performing the tests on their respective units. While each thread has an independent execution flow, it may be desirable for certain portions of the test sequence to be synchronized using batch synchronization sections. As one example, if a portion of the test sequence is operable to raise the temperature of a test chamber in which the group of units is being tested, then a one-thread-only batch synchronization section may be included in the test sequence to ensure that only one thread raises the temperature and to ensure that all threads are ready to execute the high-temperature portions of the testing process once the temperature has been raised.